home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000039_owner-urn-ietf _Tue Nov 5 10:54:12 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19174 for urn-ietf-out; Tue, 5 Nov 1996 10:54:12 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19167 for <urn-ietf@services.bunyip.com>; Tue, 5 Nov 1996 10:54:09 -0500
  3. Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA02081  (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 10:53:56 -0500
  5. Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:26 +0000
  6. Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:11 +0000
  7. Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 15:52:24 GMT
  8. Message-Id: <2.2.32.19961105155431.006d63e0@sherekhan.jungle.bt.co.uk>
  9. X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk
  10. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset="us-ascii"
  13. Date: Tue, 05 Nov 1996 15:54:31 +0000
  14. To: Fisher Mark <FisherM@is3.indy.tce.com>
  15. From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
  16. Subject: RE: [URN] Persistence as part of URN framework
  17. Cc: "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. At 07:26 05/11/96 EST, Fisher Mark wrote:
  24. >
  25. >>Persistence is a contractual
  26. >>thing which needs a technical hook to hang the contract on.
  27. >
  28. >But there are no technical hooks to guarantee persistence.  On the 
  29. >cypherpunks list a few months ago, there was a discussion of what it would 
  30. >take to encrypt a message now, save it away for 100 years, then let the 
  31. >recipient decrypt the message.  The conclusion I drew from that discussion 
  32. >was that this was a hard problem without a technical solution short of 
  33. >deploying on every desktop and in every data center a persistent OS that 
  34. >stored copies of all persistent data.  Even then, the data would only 
  35. >persist as long as technical means remained to read the persistent data. 
  36. > (How many of us could read a 600 bpi 9-track tape or punched card deck even 
  37. >if we had to?)
  38.  
  39. The point I'm making is that if we (BT) sell or give away a URN (in our role
  40. as an Internet Service Provider), to give our customers the ability to
  41. switch suppliers but keep their resource names, we will contract with them
  42. to do this for a certain time. The URN service should be able to reflect
  43. this contractual fact so that other independent systems can know how long
  44. they can rely on that person's URN (e.g. so the third party's content
  45. management system can re-check HREFs as they are about to become obsolete
  46. rather than by polling).
  47.  
  48. Once we have contracted to do this, we will *have to* ensure the URN is
  49. still accessible in terms of network infrastructure and servers. If the user
  50. has thrown away their Web browser and got SuperCrap5 instead, that's not our
  51. concern. I'm not saying we are planning doing this, I'm just laying out the
  52. processes a commercial company would go through before marketing URNs.
  53.  
  54. The same issues come up with phone number portability between suppliers.
  55.  
  56. >
  57. >The important point about URNs is that there is an extra level of 
  58. >indirection built into the resolution process, such that the URN -> URL -> 
  59. >resource resolution (in the N2L case) can transparently (at the user agent 
  60. >level) change the URL(s) associated with that URN, without changing the URN. 
  61. > Kind of a superpowered 30x redirect, in a way.  This technical detail (the 
  62. >extra level of indirection) is what will give URNs additional capability to 
  63. >persist.
  64.  
  65. That's just PURLs - saying certain names are more persistent than others.
  66. What I'm saying is that for URNs to mean anything, you need the *optional*
  67. capability to say *how* persistent you mean when you say "pretty persistent"
  68. because "for ever" is just meaningless. It must be optional because some
  69. people don't want to think about how long "persistent" means. Others might
  70. not want anyone to infer how long they expect to be in business from the
  71. length of their TTLs!
  72.  
  73. A naming service should at minimum deal with the characteristics that you
  74. can hang on a name
  75. - persistence of the name
  76. - ownership
  77. - address mapping
  78. - persistence of the address mapping
  79. - I would say "etc." but that's about it! My complaint is that two items
  80. from even this minimal list of four aren't covered by the framework (whereas
  81. the NAPTR proposal starts introducing gratuitous characteristics that are
  82. owned by the resource the name points at, not the name itself).
  83.  
  84. I would be happy if we came down on a solution which just optionally
  85. specified the longevity of the name (not the DNS NAPTR TTL because this is
  86. the longevity of the mapping, not the name itself). You could potentially
  87. have name TTLs of 10 years (or more). So a sensible discussion could now
  88. ensue as to whether this is practical - to expect any descendant of DNS to
  89. inherit any long lived TTLs from within DNS. I would say yes.
  90.  
  91. Bob
  92. ____________________________________________________________________________
  93. Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm
  94.